Pipeline, March/April 1996, vol.7, no.2
Copyright © 1996 Silicon Graphics
IRIS Performer is a powerful and extensible programming interface which integrates multiprocessed scene rendering with the IRIX operating system and REACT extensions. IRIS Performer is used to create real-time visual simulation and other interactive three-dimensional graphics applications on Silicon Graphics systems.
This article is an overview of the new features in Performer 2.0. It also includes some practical tips intended for those familiar with Performer 1.2 but who have not yet had exposure to the new release. For in-depth information about any particular feature, refer to the IRIS Performer Programming Guide, available on-line with InSight(1), or the Performer pages in Silicon Surf, available at the URL http://www.sgi.com/Technology/Performer.html.
Key New Features in IRIS Performer 2.0
IRIS Performer now includes bindings in both C and C++ and support for both the IRIS GL and OpenGL graphics libraries. Libraries for both 32-bit and 64-bit MIPS CPUs are provided.
Several new libraries have been created; IRIS Performer 2.0 consists of two conceptual main libraries, libpf and libpr (both physically contained within libpf.so); three associated libraries, libpfdu, libpfui, and libpfutil; and a group of scene database file importers collectively called libpfdb.
With the advent of OpenGL, Performer can no longer rely upon IRIS GL for interaction with the window system. Performer 1.2 provided an optional mixed-model (glx) interface to X and Motif. In Performer 2.0, the interface to the X Window System has been redesigned and made more robust; use of the new pfWindow(3pf) or pfPipeWindow(3pf) interfaces is suggested. Refer to the chapter titled "Setting up the Display Environment" in the IRIS Performer Programming Guide for complete details about the use of these functions.
Performer 2.0 adds many new simulation-oriented features, such as asynchronous scene database updates, indirect indexing of graphics state, projected texture and fog via a pfTexGen(3pf) element in the pfGeoState(3pf); better control over the range and angular attenuation, back scatter, and fog for lightpoints; enhanced Level-of-Detail (LOD) node processing and LOD state management; etc.
Other new features of more general use include multiprocessed per-channel culling, linear combinations with the new pfMorph(3pf) node, arbitrary-axis and point-rotated pfBillboard(3pf) nodes, an updated geometry mesher and builder, and text messages with the pfText(3pf) node and pfString(3pf) objects.
New Library Structure
The main components of IRIS Performer are four libraries, support files (such as the header files), and a suite of dynamic shared objects (DSOs) for database file loading.
DSO Header Name File Description libpf.so pf.h Main IRIS Performer library. Contains libpf, which handles multiprocessed scene database traversal and rendering, and libpr, which performs the optimized rendering, state control, and other functions fundamental to real-time graphics. libpfdu.so pfdu.h Library of scene and geometry building tools which greatly facilitate the construction of database loaders and converters. Includes utilities for state sharing and a triangle mesher to improve performance. libpfutil.so pfutil.h Utility-functions library. A collection of convenience routines implementing features such as smoke effects, MultiChannel Option support, graphical user interface tools, input event collection and handling, and various traversal functions. libpfui.so pfui.h GL-independent user interface library and input management facilities. libpfdb/* [dir] Directory in /usr/lib containing a collection of database loader DSOs to read data files or streams of particular formats and convert them into an IRIS Performer scene graph. Table 1. IRIS Performer librariesEach of the GL-dependent Performer DSOs have been split into IRIS GL (_igl) and OpenGL (_ogl) versions. For convenience, the base name of each library is linked to the OpenGL version (e.g., libpf.so is a symbolic link to libpf_ogl.so).
The loader libraries are named after their corresponding file extension. For example, the Wavefront obj format loader is found in /usr/lib/libpfdb/libpfobj.so (which is a link to libpfobj_ogl.so). Any number of file loaders may be accessed through the single pfdLoadFile(3pf) function, which uses special dynamic shared object features to locate and use the proper loader corresponding to the extension of the file being loaded.
Perfly(1), the main IRIS Performer demo application, also has both IRIS GL (perfly_igl) and OpenGL (perfly_ogl) variants. Perfly itself is symbolically linked to one or the other depending upon the relative performance of IRIS GL and OpenGL on each platform. For example, on an Indigo2 IMPACT system where OpenGL is the native implementation, /usr/sbin/perfly is a link to /usr/sbin/perfly_ogl. With Indigo2 EXTREME systems it is a link to perfly_igl.
Selected Library Enhancements
Asynchronous Database Updates
Loading database tiles interactively and creating a new scene subgraph from them can frequently take more time than desirable in order to maintain a fixed frame rate. In addition, Performer 1.2 did not have any facilities to prevent the user from causing data collisions between processes when making large changes to the scene graph.
The solution proposed by IRIS Performer to solve the problem of multi-process data collisions from updates to the scene graph is to perform all such updates in an asynchronous process. This asynchronous process handles all disk I/O and memory allocations and deletions completely separate from the main processing pipeline(s). To facilitate asynchronous database updates, IRIS Performer provides the pfBuffer(3pf) structure and the DBASE process.
The database (or DBASE) process can be forked by pfConfig(3pf) and a user-defined callback function provided with pfDBaseFunc(3pf), much like the channel CULL or DRAW callbacks. The database process is completely asynchronous, so if it exceeds a frame time it does not slow down rendering or intersection pipelines.
The DBASE process is intended for asynchronous database management when used with a pfBuffer. A pfBuffer is a logical buffer which isolates database changes to a single process, avoiding disastrous collisions on data from multiple processes. PfBuffers are created with pfNewBuffer(3pf), made current with pfSelectBuffer(3pf), and merged with the main IRIS Performer application scene graph with pfMergeBuffer(3pf). Default Performer database processing is then carried out by a call to pfDBase(3pf).
While the DBASE process is the one intended for pfBuffer use, other processes forked by the application may also use different pfBuffers in parallel for multi-threaded database management.
Indirect pfGeoState Specification
To view a single database with multiple appearances (such as a side-by-side normal and infrared view of the same scene), Performer 1.2 required the user to maintain two distinct copies of the scene graph or to interactively traverse and modify the pfGeoState(3pf) of objects within view just before drawing. Performer 2.0 provides a mechanism to manage this automatically, called indirect (or indexable) pfGeoStates.
In Performer 2.0, a table of pfGeoStates can be indexed by channel via pfChanGStateTable(3pf) and is automatically applied just before the channel is drawn. Any indexed pfGeoStates specified via pfGSetGStateIndex(3pf) or pfSceneGStateIndex(3pf) are accessed through the table. With a different table of pfGeoStates on each channel, the same database with various user-defined appearances can be displayed simultaneously.
Compatibility Between IRIS GL and OpenGL
IRIS Performer now provides support for the IRIS GL and OpenGL graphics libraries with a common interface for both. Calls such as pfLightColor(3pf) invoke either IRIS GL's lmdef(3G) or OpenGL's glLightfv(3G) internally, depending on the version of the Performer library used.
IRIS Performer 2.0 programmers should avoid making direct IRIS GL or OpenGL calls in their application so as to be able to link without difficulty to either version of the library. In cases where direct calls are necessary and equivalent Performer calls are not available, use -DIRISGL and #ifdef/endif sequences to separate GL from OpenGL as illustrated in the code fragment in Figure 1.
------------------------------------------------------------
/* a partial Channel DRAW callback */
static void DrawChannel (pfChannel *channel, void *data)
{
pfClearChan (channel);
pfDraw();
#ifdef IRISGL
zfunction (ZF_ALWAYS);
zwritemask (0x0);
#else /* OPENGL */
glDepthFunc(GL_ALWAYS);
glDepthMask(GL_FALSE);
#endif /* GL type */
------------------------------------------------------------
Figure 1. Use of #ifdef/endif pairs to separate IRIS GL
calls from OpenGL at compile time.
Support for IRIS GL continues to exist in Performer 2.0 because it still
provides the best performance on some platforms. For newer graphics subsystems
(such as the Indigo2 IMPACT), many OpenGL instructions are implemented in
microcode and IRIS GL is implemented as an emulation layer on top. On those
systems (and all future graphics subsystems from SGI) Performer's OpenGL-based
library is preferred.
CPU Instruction Set Compatibility and System Requirements
IRIS Performer 2.0 requires IRIX 5.3 or 6.1, and contains bindings for O32 (32-bit) IRIS GL, O32 (32-bit) OpenGL, N32 (32-bit) OpenGL, and N64 (64-bit) OpenGL.
Since this release spans two machine architecture levels (the 32-bit MIPS I/II instruction set and the 64-bit MIPS III/IV instruction set), and there are two types of 32-bit support (Old 32 and New 32), there are three versions of each library: O32, N32, and N64. The O32 version is MIPS I and can be used with MIPS I/II executables on IRIX 5.3 or IRIX 6.1 (or later). The N32 and N64 versions are MIPS III and can only be used with MIPS III/IV executables on IRIX 6.2 (or later).
In addition to DSO versions of the GL-dependent Performer libraries, there are static linking (archive or .a) versions. This release supports both optimized (-O2) and debug (-g) versions of each library.
This multidimensional complexity is hidden within IRIS Performer and the Application Programming Interface (API) is unchanged between versions. The complexity only surfaces when installing software or constructing Makefiles since consistent choices must be made throughout.
C++ Application Programmer's Interface
Performer 2.0's C++ API adds the ability to subclass and customize libpf objects to meet the programmer's needs. The C++ API is in every way equal (and in some cases superior) in functionality and performance to the C API.
Every function available in the C API is available in the C++ API. All of the C API routines tightly associated with a class have a corresponding member function in the C++ API (e.g., pfGetDCSMat(3pf) becomes pfDCS::getMat(3pf)). Routines not closely associated with a class are the same in both APIs. Examples include high-level global functions such as pfMultiprocess(3pf) and pfFrame(3pf) and low-level graphics functions such as pfAntialias(3pf).
C Routine C++ Member Function Description pfMtlColor() pfMaterial::setColor() Set material color pfGetMtlColor() pfMaterial::getColor() Get material color pfApplyMtl() pfMaterial::apply() Apply the material Table 2. Corresponding routines in the C and C++ APIC++ header files for libpf and libpr classes are in /usr/include/Performer/pf and /usr/include/Performer/pr, respectively.
Refer to the chapter titled "Programming with C++" in the IRIS Performer Programming Guide for further discussion of the C++ API.
Conclusion
Performer 2.0 contains a host of new features far more rich and detailed than can be discussed in this article. Many of the enhancements are detailed in the on-line IRIS Performer Programmers Guide, available on-line with InSight, or within the Performer section of Silicon Surf. For more information, refer to one of the following:
Mailing list
Web page
Release Notes
Programmer's Guide
FTP server
Frequently-Asked Questions